home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / misc-part2 / 10943 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.7 KB
  1. Path: nntp.teleport.com!sschaem
  2. From: sschaem@teleport.com (Stephan Schaem)
  3. Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.games,alt.sys.amiga.demos,comp.sys.amiga.misc
  4. Subject: Re: AB3D II beats Quake....
  5. Followup-To: comp.sys.amiga.programmer,comp.sys.amiga.games,alt.sys.amiga.demos,comp.sys.amiga.misc
  6. Date: 3 Apr 1996 07:11:45 GMT
  7. Organization: Teleport - Portland's Public Access (503) 220-1016
  8. Message-ID: <4jt8bh$a70@nadine.teleport.com>
  9. References: <DosA8o.17B@info.uucp> <6538.6658T1031T2526@mbox.vol.it> <4jgn4o$l2b@hell.team17.com> <4jk515$q3l@nadine.teleport.com> <4jkdpu$1o6@hell.team17.com> <4joj14$ghj@nadine.teleport.com> <4js275$98s@hell.team17.com>
  10. NNTP-Posting-Host: julie.teleport.com
  11. X-Newsreader: TIN [version 1.2 PL2]
  12.  
  13. Stefan Boberg (boberg@team17.com) wrote:
  14. : sschaem@teleport.com (Stephan Schaem) wrote:
  15.  
  16. : >Stefan Boberg (boberg@team17.com) wrote:
  17. : >: sschaem@teleport.com (Stephan Schaem) wrote:
  18.  
  19. : >: > The part that matter are in ASM... 
  20.  
  21. : >:   In Quake's case, only the scan-conversion, and some other small
  22. : >: bits. Makes perfect sense.
  23.  
  24. : > I think they should do more then just the scan conversion...
  25.  
  26. :   Such as?
  27.  
  28.  Clipping, geometry transform, bsp tree traversal, visibility test
  29.  
  30. : > Right now ID is still working on the game, my guess is by the time
  31. : > its released they will have rewriten more C part on the rendering engine
  32. : > in 486 and pentium assembly. 
  33.  
  34. :   I'm not sure about that. In DOOM, very little was in ASM.
  35.  
  36.  This just mean Doom pass most of its time in very little code.
  37.  
  38. : > Something that I recall is that ID said quake was slow on 486 because
  39. : > it uses floating point optimization for the pentium, and told they them
  40. : > would optimize it for the 486. now, was this optimization planeed as a
  41. : > compiler switch? :) 
  42.  
  43. :   Yes you can do that. You simply use in-line assembly macros for
  44. : fixed-point multiplies / divides etc. I have such a system and it
  45. : works fine. Just change a switch (such as '-DFIXED_MATH') on the
  46. : command line and all code will use fixed-point.
  47.  
  48.  Do you get good performance from this? Also I often find myself
  49.  otimizjng the fix point setting. not alway 16:16 or 8:8, but maybe
  50.  8:24, 4:28 ... I prefere to go with 'library' set of function, VS
  51.  macro. I remmeber some old stuff of mine (My first 3d experiment)
  52.  that used macro to provide math*.library VS direct 6888x assembly
  53.  with a flip of a flag, but I find this ugly.
  54.  
  55. : > where those floating point operation done during
  56. : > the scanline rasterization (bad pratice). 
  57.  
  58. :   It's not bad practice. It's clever - on the Pentium, at least. Can
  59. : you figure out why it's done?
  60.  
  61.  Nope... because the scanline loop use no MUL. and FPU add are slower
  62.  and also you cant use FPU register directly as index or else
  63.  so FPU make sense in the setup when fmul are faster then imul and you 
  64.  dont need to convert from ftoi all the time, otherwise not.
  65.  
  66.  Remember its about you 'cliaming' ID only have the scan conversion in asm
  67.  and ID 'claiming' that quake is slow on 486 because it uses float.
  68.  
  69. : > My guess is that if really
  70. : > float slow down quake on 486 is that otherpart of the engine need to
  71. : > be optimized aside the scan-conversion.
  72.  
  73. :   Not really.
  74.  
  75.  Then tell me why 1 polygon fly VS 100 ? The same number of pixel are
  76.  rasterized.... The inner scan loop is executed the same number of time
  77.  but still with 1 polygon showing quake is a few fold faster...
  78.  
  79. : > BTW do you see scan-conversion as the scan rendering loop or the
  80. : > full rasterizing routine? 
  81.  
  82. :   Taking polygon structures (vertices and edges) and turning them into
  83. : pixels.
  84.  
  85.  does the edge include slope information? if so no reason to see a float
  86.  operation in the 'scan-conversion' loop.
  87.  
  88.  I personaly used mix code... float+int with various fixpoint (float
  89.  only if the FPU is worth it)
  90.  
  91.  Stephan
  92.